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Abstract 

Aeronautical Telecommunication Network (ATN) has been developed by the International 
Civil Aviation Organization to integrate Air-Ground and Ground-Ground data communication 
for aeronautical applications into a single network serving Air Traffic Control and Aeronautical 
Operational Communications [1]. To carry time critical information required for aeronauti- 
cal applications, ATN provides different Quality of Services (QoS) to applications. ATN has 
therefore, been designed as a standalone network which implies building an expensive separate 
network for ATN. However, the cost of operating ATN can be reduced if it can be run over 
a public network such as the Internet. Although the current Internet does not provide QoS, 
the next generation Internet is expected to provide QoS to applications. The objective of this 
paper is to investigate the possibility of providing QoS to ATN applications when it is run over 
the next generation Internet. Differentiated Services (DiffServ), one of the protocols proposed 
for the next generation Internet, will allow network service providers to offer different QoS to 
customers. Our results show that it is possible to provide QoS to ATN applications when they 
run over a DiffServ backbone. 

: The work reported in this project was supported by NASA grant no. NAG3-2318 
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1 Introduction 


The International Civil Aviation Organization (ICAO) has developed the Aeronautical Telecom- 
munication Network (ATN) as a commercial infrastructure to integrate Air-Ground and Ground- 
Ground data communication into a single network to serve air traffic control and aeronautical 
operational communications [1], One of the objectives of ATN internetwork is to accommodate dif- 
ferent Quality of Service (QoS) required by ATSC (Air Traffic Services Communication) and AINSC 
(Aeronautical Industry Service Communication) applications, and the organizational policies for 
interconnection and routing specified by each participating organization. In the ATN, priority has 
the essential role of ensuring that high priority safety related and time critical data are not delayed 
by low priority non-safety data, especially when the network is overloaded with low priority data. 

The time critical information carried by ATN and the QoS required by ATN applications has led 
to the development of the ATN as an expensive independent network. The largest public network, 
the Internet, only offers point-to-point best-effort service to the users and hence is not suitable for 
carrying time critical ATN traffic. However, the rapid commercialization of the Internet has given 
rise to demands for QoS over the Internet. 

QoS is generally implemented by different classes of service contracts for different users. A 
service class may provide low-delay and low-jitter services for customers who are willing to pay 
a premium price to run high-quality applications, such as, real-time multimedia. Another service 
class may provide predictable services for customers who are willing to pay for reliability. Finally, 
the best-effort service provided by current Internet will remain for those customers who need only 
connectivity. 

The Internet Engineering Task Force (IETF) has proposed a few models to meet the demand 
for QoS. Notable among them are the Integrated Services (IntServ) model [2] and Differentiated 
Services (DifIServ) [3] model. The IntServ model is characterized by resource reservation; before 
data is transmitted, applications must set up paths and reserve resources along the path. This 
gives rise to scalability issues in the core routers of large networks. The DiffServ model is currently 
being standardized to overcome the above scalability issue, and to accommodate the various service 
guarantees required for time critical applications. The DifIServ model utilizes six bits in the TOS 
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(Type of Service) field of the IP header to mark a packet for being eligible for a particular forwarding 
behavior. It The model does not require significant changes to the existing infrastructure, and does 
not need too many additional protocols. 

A significant cost saving can be achieved if t he ATN protocol could be run over the next gen- 
eration Internet protocol as shown in Figure 1. In this paper, we are interested in developing a 
framework to run ATN over the next generation Internet. This requires appropriate mapping of 
parameters at the edge routers between the two networks. The objective of this paper is to investi- 
gate the QoS that can be achieved when ATN runs over the DiffServ network in the next generation 
Internet. Based on the similarity between an IP packet and an ATN packet, our approach is to 
add a mapping function to the edge DiffServ router so that the traffic flows coming from ATN can 
be appropriately mapped into the corresponding Behavior Aggregates of DiffServ, and then marked 
with the appropriate DSCP (Differentiated Service Code Point) for routing in DiffServ domain. 
We show that, without making any significant changes to the ATN or DiffServ infrastructure and 
without any additional protocols or signaling, it is possible to provide QoS to ATN applications 
when ATN runs over a DiffServ network. 

The significance of this work is that considerable cost savings could be possible if the next 
generation Internet backbone can be used to connect ATN subnetworks. The main contributions 
of this paper can be summarized as follows: 

• Propose a framework to run ATN over the DiffServ network. 

• Show that QoS can be achieved by end ATN applications when run over the next generation 
Internet. 

The rest of this paper is organized as follows. In Sections 2 and 3, we briefly present the 
main features of ATN and DiffServ, respectively. In Section 4, we describe our approach for the 
interconnection of ATN and DiffServ and the simulation configuration to test the effectiveness of 
our approach. In Section 5, we analyze our simulation results to show that QoS can be provided 
to end applications in the ATN domain. Concluding remarks are finally given in Section 6. 
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Figure 1: Interconnection between ATN and Differentiated Services. 

2 Aeronautical Telecommunication Network (ATN) 


In the early 1980s, the International Civil Aviation Organization (ICAO ) recognized the increasing 


limitations of the present air navigation systems and the need for improvements to take civil aviation 


into the 21st century. The need for changes in the current global air navigation system is due to 


two principal factors: 


• The present and growing air traffic demand which the current system will be unable to cope. 

• The need for global consistency in the provisioning of air traffic services during the progression 
towards a seamless air traffic management system. 

The above factors gave rise to the concept of the Aeronautical Telecommunication Network (ATN) [4]. 

ATN is both a ground-based network providing communications between ground-based users, 
and an air-ground network providing communications between airborne and ground users. It was 
always intended that ATN should be built on existing technologies instead of inventing new ap- 
proaches. The Internet approach was seen as the most suitable approach, and was therefore selected 
as the basis for the ATN. ATN is made up of End Systems, Intermediate Systems, ground-ground 
subnetworks and air-ground subnetworks as shown in Figure 1. 
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2.1 Priority in ATN 


The ATN has been designed to provide a high reliability/availability network by ensuring that 
there is no single point of failure, and by permitting the availability of multiple alternative routes 
to the same destination with dynamic switching between alternatives. Every ATN user data is 
given a relative priority on the network in order to ensure that low priority data does not impede 
the flow of high priority data. The purpose of priority is to signal the relative importance and 
(or) precedence of data, such that when a decision has to be made as to which data to act first, 
or when contention for access to shared resources has to be resolved, the decision or outcome 
can be determined unambiguously and in line with user requirements both within and between 
applications. 

Priority in ATN is signaled separately by the application in the transport layer, network layer, 
and in ATN subnetworks, which gives rise to Transport Priority, Network Priority and Subnet 
Priority [5]. Network priority is used to manage the access to network resources. During periods of 
high network utilization, higher priority NPDUs (Network Protocol Data Units) may therefore be 
expected to be more likely to reach their destination (i.e. be less likely to be discarded by a congested 
router), and to have a lower transit delay (i.e. be more likely to be selected for transmission from 
an outgoing queue) than lower priority packets. In this paper, we focus on network priority which 
determines the sharing of limited network resources. 

2.2 ATN packet format 

Figure 2 shows the correspondence between the fields of an IP packet header and the network layer 
packet header of ATN. It is seen that the fields of IP and ATN packets carry similar information, 
and thus can almost be mapped to each other. This provides the possibility for mapping ATN 
to DiffServ (which uses the IP packet header except for the Type of Service byte) to achieve the 
required QoS when they are interconnected. 

The NPDU header of an ATN packet contains an option part including an 8-bit field named 
Priority which indicates the relative priority of the NPDU [1]. The values 0000 0001 through 
0000 1110 are to be used to indicate the priority in an increasing order. The value 0000 0000 
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IP Packet 


ATN Packet 



Figure 2: Similarity between an IP packet and an ATN packet 


indicates normal priority. 


3 Differentiated Services 

Differentiated services (Diffserv) is intended to enable the deployment of scalable service discrimi- 
nation in the Internet without the need for per-flow state and signaling at every hop. The premise 
of Diffserv networks is that routers in the core network handle packets from different traffic streams 
by forwarding them using different per-hop behaviors (PHBs). The PHB to be applied is indicated 
by a Diffserv Codepoint (DSCP) in the IP header of the packet [6]. The advantage of such a 
mechanism is that several different traffic streams can be aggregated to one of a small number of 
behavior aggregates (BA) which are each forwarded using the same PHB at the router, thereby 
simplifying the processing and associated storage [7]. There is no signaling or processing since QoS 
(Quality of Service) is invoked on a packet- by- packet basis [7]. 

The Diffserv architecture is composed of a number of functional elements, including a small set 
of per-hop forwarding behaviors, packet classification functions, and traffic conditioning functions 
which includes metering, marking, shaping and policing. The functional block diagram of a typical 


N AS A/TM— 2001-2 1 0754 


6 








messages 


Figure 3: Major functional block diagram of a router. 


Diffserv router is shown in Figure 3 [7]. This architecture provides Expedited Forwarding (EF) 
service and Assured Forwarding (AF) service in addition to best-effort (BE) service as described 
below. 


3.1 Expedited Forwarding (EF) 

This service is also been described as Premium Service . The EF service provides a low loss, low 
latency, low jitter, assured bandwidth, end-to-end service for customers [8], Loss, latency and jitter 
are due to the queuing experienced by traffic while transiting the network. Therefore, providing 
low loss, latency and jitter for some traffic aggregate means there are no queues (or very small 
queues) for the traffic aggregate. At every transit node, the aggregate of the EF traffic’s maximum 
arrival rate must be less than its configured minimum departure rate so that there is almost no 
queuing delay for these premium packets. Packets exceeding the peak rate are shaped by the traffic 
conditioners to bring the traffic into conformance. 

3.2 Assured Forwarding 

This service provides a reliable services for customers, even in times of network congestion. Classi- 
fication and policing are first done at the edge routers of the DifFServ network. The assured service 
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Figure 4: AF classes with drop precedence levels 


traffic is considered in-profile if the traffic does not exceed the bit rate allocated for the service; oth- 
erwise, the excess packets are considered ou£-of-profile. The in-profile packets should be forwarded 
with high probability. However, the onf-of-profile packets are not delivered with as high probability 
as the traffic that is within the profile. Since the network does not reorder packets that belong to 
the same microflow, all packets, irrespective of whether they are in- profile or ouf-of-profile, are put 
into an assured queue to avoid out-of-order delivery. 

Assured Forwarding provides the delivery of packets in four independently forwarded AF classes. 
Each class is allocated with a configurable minimum amount of buffer space and bandwidth. Each 
class is in turn divided into different levels of drop precedence. In the case of network congestion, 
the drop precedence determines the relative importance of the packets within the AF class. Figure 
4 [9] shows four different AF classes with three levels of drop precedence. 

3.3 Best Effort 

This is the default service available in DiffServ, and is also deployed by the current Internet. It 
does not guarantee any bandwidth to the customers, but can only get the bandwidth available. 
Packets are queued when buffers are available and dropped when resources are over committed. 

4 ATN over Differentiated Services 

In this section, we describe in detail the mapping strategy adopted in this paper to connect the 
ATN and DS domains followed by the simulation configuration we have used to test the mapping. 
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Figure 5: Mapping function for ATN over Differentiated Service. 


4.1 Mapping Function 

Our goal is to use differentiated services to achieve QoS for ATN to integrate Air/Ground and 
Ground/Ground data communications into a global Internet serving Air Traffic Control (ATC) and 
Aeronautical Operations Communications (AOC). The main constraint is that the PHB treatment 
of packets along the path in the DiffServ domain must approximate the QoS offered in the ATN 
network. In this paper, we satisfy the above requirement by appropriately mapping the traffic 
coming from ATN into the corresponding Behavior Aggregates, and then marking the packets with 
the appropriate DSCP for routing in the DiffServ domain. 

To achieve the above goal, we introduce a mapping function at the boundary router between 
the ATN and DiffServ domain as shown in Figure 5. Packets with different priorities from the 
ATN domain are first mapped to the corresponding PHBs in the DiffServ domain by appropriately 
assigning a DSCP according to the mapping function. The packets are then routed in the DiffServ 
domain where they receive treatment based on their DSCP code. The packets are grouped to BAs 
in the DiffServ domain. Table 1 shows an example mapping function which has been used in our 
simulation. 

Table 1: An example mapping function used in our simulation. 


A TN Priority Code 

Priority 

PHB 

DSCP 

0000 0000 

Normal 

BE 

000000 

0000 0111 

Medium 

AF11 

001010 

0000 1110 

High 

EF 

101110 
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Figure 6: Network configuration 


4.2 Simulation Configuration 

To test the effectiveness of our proposed mapping strategy between ATN and DiffServ and to 
determine the QoS that can be provided to ATN applications, we carried out simulation using 
the ns (Version 2.1b6) simulation tool from Berkeley [10]. The network configuration used in our 
simulation is shown in Figure 6. 

Ten ATN sources were used in our simulation, the number of sources generating high , medium 
and normal priority packets were two, three and five respectively. Ten ATN sinks served as desti- 
nations for the ATN sources. 

All the links in Figure 6 are labeled with a ( bandwidth , propagation delay) pair. For the purpose 
of ATN over Diffserv, the mapping function shown in Table 1 has been integrated into the edge 
DiffServ router. CBR (Constant Bit Rate) traffic was used for all ATN sources in our simulation 
so that the relationship between the bandwidth utilization and bandwidth allocation can be more 
easily evaluated. 

Inside the DiffServ router, EF queue was configured as a simple Priority Queue with Tail 
Drop. AF queue was configured as RIO queue and BE queue as a RED [11] queue. The queue 
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weights of EF, AF and BE queues were set to 0.4, 0.4 and 0.2 respectively. Since the bandwidth 
of the bottleneck link between two DiffServ routers is 5 Mb, the above scheduling weights implies 
bandwidth allocations of 2 Mb, 2 Mb and 1 Mb for the EF, AF and BE links respectively during 
periods of congestion at the edge router. 

5 Simulation Results 

In this section, results obtained from our simulation experiments are presented. The criteria used 
to evaluate our proposed strategy are described followed by the description of our experiments and 
numerical results. 

5.1 Performance Criteria 

To show the effectiveness of our mapping strategy in providing QoS to end ATN applications, we 
have used goodput, queue size and drop ratio as the performance criteria. In the next section, we 
present the results of measurements of the above quantities from our simulation experiments. 

5.2 Simulation Cases 

We use the following four simulation cases to determine the QoS obtained by ATN sources. 

• Case 1: No congestion: The traffic generated by the each high, medium and normal 
priority sources were set to 1 Mb, 0.666 Mb and 0.2 Mb respectively. According to the network 
configuration described in Section 4.2, there are two, three and five sources generating high, 
medium and normal priority traffic of 2Mb, 2Mb and 1Mb respectively. The amount of 
traffic of different priority are equal to the corresponding output link bandwidth assigned by 
scheduler described in Section 4.2. Under this scenario, there should not be any significant 
congestion at the edge DiffServ router because the sum of the traffic from the sources is equal 
to the bandwidth of the bottleneck link. 

• Case 2: Normal priority traffic gets into congestion: The traffic generated by the 
each high, medium and normal priority sources were set to 1 Mb, 0.666 Mb and 0.6 Mb 
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respectively. According to the network configuration described in Section 4.2, there are two, 
three and five sources generating high, medium and normal priority traffic of 2Mb, 2Mb 
and 3Mb respectively. The amount of traffic of high and medium priority are still equal 
to the corresponding output link bandwidth assigned by scheduler described in Section 4.2. 
However, the amount of traffic of normal priority is greater than its corresponding output 
link bandwidth. Under this scenario, the normal priority traffic gets into congestion at the 
edge Diffserv router. 

• Case 3: Medium priority traffic gets into congestion: The traffic generated by the 
each high, medium and normal priority sources were set to 1Mb, 1.333 Mb and 0.2 Mb 
respectively. According to the network configuration described in Section 4.2, there are two, 
three and five sources generating high, medium and normal priority traffic of 2Mb, 4Mb 
and 1Mb respectively. The amount of traffic of high and normal priority are still equal to 
the corresponding output link bandwidth assigned by scheduler described in Section 4.2. 
However, the amount of traffic of medium priority is greater than its corresponding output 
link bandwidth. Under this scenario, the medium priority traffic gets into congestion at the 
edge Diffserv router. 

• Case 4: Both medium and normal priority traffics get into congestion: The traffic- 
generated by the each high, medium and normal priority sources were set to 1Mb, 1.333 Mb 
and 0.6 Mb respectively. According to the network configuration described in Section 4.2, 
there are two, three and five sources generating high, medium and normal priority traffie 
of 2Mb, 4Mb and 3Mb respectively. The amount of traffic of high priority is still equal 
to the corresponding output link bandwidth assigned by scheduler described in Section 4.2. 
However, the amount of traffic of both medium and normal priority are greater than their 
corresponding output link bandwidth. Under this scenario, both medium and normal priority 
traffics get into congestion at the edge Diffserv router. 
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5.3 Numerical Results 


Table 2 shows the goodput of each ATN source for four different cases described in Section 5.2. 
Table 3 shows the drop ratio measured at the scheduler for four cases of the three different types 
of ATN sources. Figures 7, 8. 9 and 10 show the queue size for each of the four case (from Case 1 
to Case 4), from which the queuing delay and jitter can be evaluated. 


Table 2: Goodput of each ATN source (Unit: Kb/S) 


Sources 

Case 1 

Case 2 

Case 8 

Case 4 

High priority Sources 

Source 0 

999.9990 

999.9990 

999.9990 

999.9990 


Source 1 

999.9990 

999.9990 

999.9990 

999.9990 


Source 2 

666.6660 

666.6660 

668.2409 

668.4719 

Medium priority Sources 

Source 3 

666.6660 

666.6660 

667.3379 

667.5270 


Source 4 

666.6660 

666.6660 

664.4189 

663.9990 


Source 5 

200.0039 

199.6469 

200.0039 

199.4790 


Source 6 

200.0039 

201.8520 

200.0039 

201.9780 

Normal priority Sources 

Source 7 

200.0039 

202.4190 

200.0039 

201.6840 


Source 8 

199.9830 

199.8779 

199.9830 

200.4660 


Source 9 

200.0039 

196.2030 

200.0039 

196.3920 


Table 3: Drop ratio of ATN traffic. 


Type of traffic 

Case 1 

Case 2 

Case 3 

Case 4 

High priority Traffic 

0.000000 

0.000000 

0.000000 

0.000000 

Medium priority Traffic 

0.000000 

0.000000 

0.499817 

0.499834 

Normal priority Traffic 

0.000000 

0.665638 

0.000000 

0.665616 


Case 1 is an ideal case. Each type of source (high, medium and normal priority sources) 
generates traffic at the rate equal to the bandwidth assigned by the scheduler. Therefore, there is 
no significant network congestion at the edge Diffserv router. As seen in Table 2, the goodput of 
each source is almost the same as its traffic generation rate. From Table 3, the drop ratio of each 
type of sources is zero. Figure 7 shows the queuing performance of each queue. Because this is an 
ideal case, the size of each queue is very small. Though the three queues have almost the same 
average size, we observe that the normal priority queue (mapping to BE queue, according to the 
mapping function) has the largest jitter, delay). 
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Figure 7: Queue size plots for Case 1 
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Figure 8: Queue size plots for Case 2. 
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In case 2, we increased the traffic generation rate of normal priority sources, keeping the rates 
of the other two types of traffic unchanged. The traffic generating rate of each normal priority 
source is set to 0.6Mb. In this case, the normal priority traffic gets congested. As shown by Table 
3, the drop ratio of normal priority traffic is greatly increased. However, drop ratio for the other 
two sources still remain at zero. As seen in Table 2, the goodput of normal priority traffic for each 
source is only about 0.2Mb, instead of the traffic generation rate of 0.6Mb. The reason is that the 
total available output bandwidth of normal priority traffic has been assigned to 1Mb by scheduler. 
From Figure 8, we find that the average queue size of the normal priority queue is far greater than 
the other two types of sources. In addition, the jitter of normal priority traffic is also greater than 
the other two types of sources. The high priority traffic has the smallest average queue size and 
the smallest jitter. 

Case 3 is very similar to case 2. The only difference is that the medium priority traffic, rather 
than normal priority traffic, gets into congestion. As expected, we find the drop ratio of medium 
priority traffic is increased with other two traffic types remaining at zero, and the goodput is also 
limited by the output link bandwidth assigned by the scheduler (which is 2Mb). From Figure 9, 
we find that both the jitter and the average queue size of medium priority traffic are far greater 
than the other two traffic types. The high priority traffic has the smallest average queue size and 
the smallest jitter. 

In Case 4, we increased the traffic generation rates of both medium and normal priority sources. 
Both of them get into network congestion in this case. We find from Table 3 that the drop ratio 
of high priority traffic remains at zero, and drop ratios of both medium priority traffic and normal 
priority traffic are greatly increased. Furthermore, the drop ratio of normal priority traffic is greater 
than that of medium priority traffic. As shown by Table 2, the goodput of both the medium and 
normal priority traffic are limited by their link bandwidths allocated by scheduler. From Figure 
10, we see that the normal priority traffic has both the biggest jitter and biggest average queue 
size. We can also find that the high priority traffic has both the smallest jitter and smallest average 
queue size. 

From the above results, we can arrive at the following observations : 
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• The high priority traffic always has the smallest jitter, the smallest average queue size and the 
smallest drop ratio without being affected by the performance of other traffic. In other words, 
the high priority traffic receives the highest priority, which satisfies the priority requirements 
of ATN. 

• The medium priority traffic has smaller drop ratio, jitter and queue size than the normal 
priority traffic, even in the presence of network congestion. This also satisfies the priority 
requirements of ATN. 

We therefore, conclude that the priority requirements of ATN can be successfully achieved when 
ATN traffic is mapped to the DiffSei'v domain in next generation Internet . 

6 Conclusion 

In this paper, we have proposed DiffServ as the backbone network to interconnect ATN subnetworks. 
We have designed a mapping function to map traffic flows coming from ATN with different priorities 
(indicated by the priority field in ATN packet header) to the corresponding PHBs in the DiffServ 
domain. 

The proposed scheme has been studied in detail using simulation. It has been found that the 
QoS requirements of ATN can be achieved when ATN runs over DiffServ. We have illustrated our 
scheme by mapping ATN traffic of three different priorities to the three service classes of DiffServ. 
The ability of our scheme to provide QoS to end ATN applications has been demonstrated by 
measuring the drop ratio, goodput and queue size. We found that the high priority ATN traffic has 
the smallest jitter, the smallest average queue size and the smallest drop ratio, and is unaffected 
by the performance of other traffic. Moreover, the medium priority ATN traffic has a smaller drop 
ratio, jitter and queue size than the normal traffic, even in the presence of network congestion. 
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